リバースプロキシを使用して自社ドメイン上で API リクエストをホストする方法

概要

進化するデジタル環境とクライアント固有ドメインでのホスティング

今日の急速に進化するデジタル環境において、ビジネスには、運用ニーズやセキュリティ基準に適合した堅牢で安全な API 統合が求められています。

API リクエストをリバースプロキシを通じて自社ドメイン経由でルーティングすることで、ブラウザやメールクライアントとのやり取りをより効率的かつ信頼性の高いゲートウェイ経由で行うことが可能となります。このアプローチは、従来のベンダーのサードパーティドメイン依存型の方法に比べて多くの利点があります。

  • セキュリティと管理性の向上：API トラフィックを自社ドメイン内にとどめることで、完全な管理下に置くことができ、組織固有の要件に沿ったセキュリティポリシーを適用できます。

  • 信頼性の向上：サードパーティドメインに依存することは、その稼働時間や応答速度に左右されることを意味します。API リクエストを自社ドメインにプロキシすることで、サービスの信頼性を自社で管理し、安定したパフォーマンスを確保できます。

  • ブランドの一貫性：ドメインはブランドアイデンティティの重要な要素です。API トラフィックを自社ドメイン経由にすることで、ブランド体験を統一し、信頼性と信用を強化できます。

  • クロスオリジンリソース共有（CORS）対応：自社ドメインでの API リクエストは、CORS に伴う複雑さを回避でき、ウェブアプリケーションとのデータ交換プロセスを簡素化します。

  • 将来の柔軟性：ビジネスの進化に合わせて API 戦略も柔軟に対応する必要があります。API を自社ドメイン上に構成しておくことで、バックエンドベンダーの変更やスケールアップ時にもクライアントアプリケーションを変更せずに対応可能です。

API ゲートウェイとしてのリバースプロキシ

このガイドでは、Web ブラウザやメールクライアントが Personalization Cloud への直接 API コール（recs.richrelevance.com、https://image.richrelevance.com、または recs.algorecs.com 経由）をクロスオリジンとしてマークしないようにするための、リバースプロキシの構築手順を紹介します。顧客環境でリバースプロキシを構成することで、以下が可能になります：

1. Web ブラウザを構成し、Personalization Cloud へのすべての API リクエストを自社ドメイン経由でルーティング

Note: Web ブラウザでの直接 API 統合の詳細は、API（Recommend）のクライアントサイド実装を参照してください。

2. メール開封時やリンククリック時の API リクエストも自社ドメインを経由するように設定

Note: メールレコメンデーションの設定に関する詳細は、Email Setup、Content in Email Guide、および Recommend in Email Best Practices Overview を参照してください。

以下のセクションでは、AWS Cloud が提供するサービスを使用したリバースプロキシソリューションの構築方法を説明します。API Gateway Reverse Proxy は、任意の公開 API Gateway ソリューションで設定できます。本ガイドで参照されるサービスは以下のとおりです：

  • API Gateway：クライアントのリクエストを Personalization Cloud ドメインにプロキシし、自社ドメイン裏でのレスポンスのようにレンダリングする中核サービス。

  • Route53（DNS サービス）：カスタマードメインと API Gateway の生成 URL をマッピングするために使用。

  • ACM SSL 証明書：ユーザー向け URL となるクライアントのサブドメインに SSL 証明書をインストールするために使用。

Note: 任意の API Gateway ソリューションと DNS、証明書管理サービスの組み合わせで、リバースプロキシソリューションを構築可能です。

リバースプロキシの構成

API Gateway のセットアップ

以下の手順に従って、API Gateway をリバースプロキシとして構成します：

  1. API Gateway コンソールで HTTP API を作成し、名前を指定します（例：「RR-Email-Images」など）。

  2. 他のオプションはデフォルトのままで Next をクリックし、Create をクリック。

  3. Develop セクションの Routes を選択し、「RR-Email-images」API にルートを作成。

  1. Develop セクション内の Integrations を選択して、ルートとの統合を設定します。

    1. Attach integrations to routes の下で該当ルートを選択します。

    2. HTTP URI - ANY をドロップダウンから選択します。

    3. Integration details for route の下で、URL（https://image.richrelevance.com/{proxy} または https://recs.richrelevance.com/rrserver/api/rrPlatform/recsForPlacements/{proxy}）を入力します。

  1. その他の設定はデフォルトのままにし、Create をクリックします。

  2. 他のルートが存在する場合は、ステップ (i) ～ (iv) を繰り返して統合を追加します。

カスタムドメインの作成

次に、ユーザー向けのカスタムドメインを作成し、SSL オフロードを設定します。

  1. API Gateway サービスで Custom domain names を選択します。

  2. TLS 設定は TLS 1.2 のままで構いません。

  3. Endpoint configuration では、regional を選択します。

  4. ドメインに対応する SSL 証明書を選択します。

  5. Create domain name をクリックします。

    Note: 上記画像ではカスタムドメインとして https://rremailimages.algonomy.com が作成されています。

  6. 作成したカスタムドメインで API mappings を選択します。

  7. Configure API mappings をクリックし、該当 API とデフォルトステージを選択します。

  8. Save をクリックします。

  9. カスタムドメインの設定画面で API Gateway domain name を控えておき、DNS マッピングに使用します。

DNS マッピング

DNS サービスで、クライアントのカスタムドメインと、前のステップで取得した API Gateway ドメイン名 の CName マッピングを行います。

動作確認（Sanity Test）

このガイドでは、Algonomy の Personalization Cloud のメールソリューションを使用して送信したメールに含まれる画像やリンクを、顧客自社ドメインで表示させるシステムのセットアップ方法を紹介します。これにより、顧客がメールを開いた際、自社のウェブサイトからコンテンツが提供されるように見せることができます。

Note: この方法は、richrelevance または algorecs ドメイン上で API を提供している Personalization Cloud のあらゆるサービスに適用可能です。

API リバースプロキシを適用する前のメール開封時のリクエスト例。https://image.richrelevance.com への直接の HTTP コールが発生しています。

Copy 
https://image.richrelevance.com/rrmail/image/recs?apiKey=4b66fc099e9db879&userId=3baa46d3a97bbda70fcd8d28825d02c8178f2dc1&campaign=teste&date=202303240345&placement=ep_nav_cv&layout=price_tag_2&region=&productId=product_uuid&categoryId=1062397158&orderId=&brandId=&slot=1&additionalClickURLData=strategyName&utm_source=newsletter&utm_medium=e-mail_journey&utm_campaign=teste&utm_content=un54&utm_term=RR1

API リバースプロキシ適用後の同じメール開封リクエスト。画像が https://rremailimages.algonomy.com から提供されていることが確認できます。

API ゲートウェイのプロキシリソース

プロキシリソースとは、API 内で特定のリソースパスに一致しないすべてのパスセグメントをキャッチし、バックエンドサービスにそのままフォワードする特別な種類のリソースです。

正確には、定義されたリソースパスに一致しないすべてのリクエストをキャッチし、サブパスを含むリクエスト全体のパスを統合先のバックエンドサービスに転送します。これにより、個別リソース／パスを定義せずに多様な動的 URL を処理可能になります。

類似アプローチとそのトレードオフ

  1. ワイルドルート：AWS API Gateway におけるプロキシリソースのような機能は、すべてのオープンソース API ゲートウェイに共通するわけではありません。Kong や Tyk など一部のオープンソースゲートウェイでは * や /:wildcard のようなパターンでワイルドカードルートを定義できます。

  2. キャッチオールエンドポイント：特定のオープンソース API ゲートウェイでは、未定義のパスをすべてキャッチするエンドポイントが定義可能です。NGINX では proxy_pass を使ってバックエンドへのリクエスト転送が可能です。

  3. 使いやすさ：オープンソースの API ゲートウェイソリューションでは、AWS API Gateway のようなプロキシリソース機能に近い柔軟性やカスタマイズが提供される場合もありますが、分析や PoC が必要になることがあります。また、開発者はリクエストのパスやヘッダー、その他の条件に応じて動的にルーティングを処理するコードを記述できますが、AWS API Gateway の事前構築された機能と比較すると、開発負荷が増加します。

さらに、API ゲートウェイ以外のアプローチでは、個別パスやルートの管理が複雑になる傾向があります。